Presence services are primarily used for providing “availability” information of one user to another user of a system. This “availability” information includes an indication of desire and availability or willingness of the user to engage in immediate communication. In order to achieve immediate communication a Presence Service is used to convey contact information to a user's presence client and the presence client is required to use that information to determine how to connect the users. This is particularly difficult when the communication services are developed by a third party vendor. Communication services include any application that creates a communication path between two or more parties. Examples of such services include telephone voice connections, Instant Messaging, chat, video conferencing, and sharing of presentations.
Existing Presence, or Instant Messaging (IM), services rely on a fixed and a built-in set of communication connection aids. For example, in order to enable communication via instant messaging services such as MSN and AOL, the communication service is normally tightly coupled with the presence service. These communication services are developed by the same vendor and usually pass through the IM server.
The prior art suffers inherent disadvantages because they are “closed” systems. There is no flexible way to add other telephony or communication services to these systems. For example, the existing Instant Messaging systems cannot add a non-IP phone call set via third party voice products. The communication connections of these systems are hardwired and limited. While this may be suitable for IM chat style of communication services, it is not suitable for other communication services, for example, existing telephony services.
Several standard bodies are attempting to define how contact information is conveyed with a user's availability in a presence framework. Of particular interest is the IETF Instant Message and Presence Protocol (IMPP) set forth in “A Model for Presence and Instant Messaging”, M. Day, J. Rosenberg, and H. Sugano, IETF RFC 2778, February 2000. Two further IETF documents discuss the Common Profile for Instant Messaging (CPIM). These two documents are the Common Presence and Instant Messaging: Message Format document (Common Presence and Instant Messaging: Message Format <draft-ietf-impp-cpim-msgfmt-03.txt>) and the CPIM Presence Information Data Format (CPIM Presence Information Data Format <draft-ietf-impp-cpim-pidf-00.txt>).
The Common Presence and Instant Messaging: Message Format document defines a mime content-type ‘message/cpim’ object which is a multipart entity. This document defines the structure of an IM message specifying mandatory fields such as “From:”, “To:”, “Date:”, “Subject:”, etc. The second document, CPIM Presence Information Data, defines the actual contact information that a presence client receives in order to enable a communication session between two users of a presence service. This document does not discuss how a presence client uses contact information for launching third party communication applications.
There is no flexible way to enhance any existing Presence (or Availability) Service to handle communication connection via third party communication products.